Loading...
 

Business processes - Purchasing

Business Processes Purchasing

General overview of the shopping area

Bproc Purch En

The purchasing area is characterised not only by the procurement itself, but also by preceding and subsequent processes. Thus, a demand fulfilment is usually based on a demand that may have arisen through the most diverse types. These include the customer requirement (order item, production parts list, gozo item), as well as the requirement of a cost centre. Through the B&B list, requirements of stock parts (quantity shortfall) and/or of dispositive purchase parts (deadline control) can be uncovered. Other requirements can of course also be recorded.

The next step is the requirement request, the precursor of the order. Rules can be established here under which the requirement coverage requests must pass through an approval cycle.

Now the actual purchasing department comes into play, which creates the order according to the request data (part, quantity, delivery date) and the information from the order role of the part and the supplier agreements (delivery time, price, conditions, ...). If information is not sufficiently available, the buyer can also make a request to the supplier. He is supported by the possibility of comparing prices. If a framework order exists with the supplier, the buyer can also use the release order.

The documents following in the document history only affect the purchase order in so far as they have an influence on the status of the order. For example, a purchase order is only reported as complete when goods receipt or direct delivery documents have been created for the entire order quantity. The incoming invoice therefore has a corresponding influence on the billing status of the purchase order.

Order of services

Ordered services are reported ready by checking the box "No (further) goods receipt expected" in the group "Process control" on the delivery schedule of the follow-up order, as there should be no goods receipt for this.

Exceptions are orders for services in the case of external work sequences, i.e. if provisions are sent to the supplier with which, for example, the surface treatment is stated on the order as a unit of performance. Here it is perfectly legitimate to generate a goods receipt and even a QA for the unit of performance, since the performance can also be checked directly. If, for example, 3 out of 10 parts to be galvanised are not completely galvanised, a return document can be generated and thus a subsequent claim for this service.

Approval procedure

By means of the settings in the client and in the cost centres (organisation chart), the approval procedure of the requirement requests (BA), the purchase orders and/or the incoming invoices can be activated and a control system can be set up. In addition to the control system, it is also possible (depending on the settings) to define an approver manually.

General definitions and rules

  • The client defines which employees may approve procurement processes.
  • For the automatic set of rules for determining the approvers, it must be possible to determine a responsible cost centre for each item. This is used to determine the approver as the cost centre manager of this or a higher cost centre according to the organisation chart.
  • The rulebook checks the items for their type and value, not the entire document. A requirement request, for example, must therefore be approved as a whole if at least one item exceeds a defined value limit according to the set of rules. The total value of the requirement coverage request is therefore irrelevant for approval.
  • The following applies to requisitions and purchase orders: An approver may not be proposed by the system as an approver for another cost centre. In this case, the items must be split up into several requirement coverage requests, for example.
  • The client defines which documents (requisitions, purchase orders or purchase invoices) all have to be approved according to the set of rules. If approval is activated for several or even all documents in the document chain, the following rule applies:
    - A document does not have to be approved if a predecessor has already been approved and the approver of the successor does not belong to a higher level in the organisation chart.

    Example:
    A requisition has been approved and the purchase invoice has been raised above the purchase order value set in the BA.
    -> The ER does not need to be approved.

    A requisition was not approved and the purchase invoice was issued for an amount that would have resulted in approval in the BA.
    -> The ER must be approved.

    A requisition was approved and the purchase invoice was for an amount that would have resulted in a higher approver in the BA.
    -> The ER must be approved.

Authorisation procedure for requisitions

The approval procedure begins to take effect already during the creation of the requisition by the automatic/manual setting of the approver, but it actively influences the purchasing process but only after the requisition has been posted. If an approver was determined/set at the time of posting, the BA is not automatically released and no purchase order can be generated for the items.

The BA is now checked manually. On the one hand, the approver can see via his processes which BAs he has to check, on the other hand, the purchasing department can check via the BA status list which BAs still have to be checked to make sure that no BAs are left hanging. From both lists, the module for releasing/rejecting the BA(see here) can be called.

If the BA has been approved, the purchasing department can now generate the order(s) using the tools at its disposal.

However, to ensure that rejected requisitions are not lost, as the need is likely to still exist, the process is not yet complete here. In the case of rejection, the requirement coverage request is returned to the processor and is available for postprocessing or post-maintenance. The requirement coverage request must then be posted again (activated) and appears for resubmission to the approver. Acceptance of the rejection should be indicated by the cancellation of the requirement coverage request by its processor.

Approval procedure for orders

The approval procedure for orders is similar to that for requisitions. Thus, the rules defined in the client and in the cost centres are also applied here. The only difference is that order items that have already been preceded by a requirement request no longer need to be approved.

Unapproved orders cannot be printed or otherwise output.

Using the list window of the orders, the purchasing department can check whether orders in the status "to be approved" get stuck and follow up with the approver.

Since non-approved orders cannot be printed and are therefore not automatically printed directly, mass printing takes into account the newly approved but not yet printed orders.

Approval procedure for incoming invoices

The approval procedure for incoming invoices is also similar to that for requisitions and orders. Thus, the rules defined in the client and in the cost centres are also applied here. The following special features are applied in the approval procedure for incoming invoices:

  • The type of incoming invoices is not set directly in the items as in the requisitions and orders. If the incoming invoice is preassigned to a cost object, it is considered an order requirement, otherwise it is considered an internal requirement. The type storage requirement is not taken into account here, as in this case an order is expected.
  • If all items can be approved by a cost centre manager, only the incoming invoice header must be approved. In this case, only the A/P invoice is displayed in the approver's transaction folder. If the A/P invoice must be approved by different employees, the items are submitted to the different approvers via the transaction folder.

An incoming invoice is not released if it has not been approved. In addition, an A/P invoice is not presented to the approver until it has been verified.

Approval and verification are two different processes, which are usually also carried out by different employees. During the check, the correctness of the incoming invoice is checked by the person in charge (buyer, requester, etc.). The incoming invoice is then approved by the cost centre manager.

Signature regulations

By means of the settings in the client, the signature control for orders can be activated and a control system can be set up. This makes it possible to use the four-eye principle for checking orders in the system! Only when both signatures have been digitally confirmed is the order approved. Subsequent changes can only be made within a defined framework without the consent of the signatory.

General definitions and rules

  • The client defines which employees can execute the 1st or 2nd signature.
  • The signature regime is separate from the authorisation procedure.
  • For the automatic rule set to determine the users for the 1st or 2nd signature.
  • Each user can define one deputy per signature for a period of time or unlimited in his user settings.
  • Via the menu item "Orders to be signed" and in the transaction documents, the user can check whether he/she has to sign orders.

Overview of the workflow of a delivery schedule line

The business process of an order item (delivery schedule line item) could look like this, for example.

Workflow Order Item En

Further topics

Operational business